In small telecommunications networks, certain network services or functions, such as a policy and charging rules function (PCRF), may be adequately performed via a single node. Routing nodes, such as Diameter signaling routing nodes, are configured to route messages to and from the various functions as needed. Networks may be scalable, such that smaller networks can add nodes thereby scaling up in size (e.g., become larger) for accommodating increased traffic, where needed.
Larger networks require multiple nodes for performing a same function, such as multiple PCRF nodes, multiple policy and charging enforcement function (PCEF) nodes, multiple application function (AF) nodes, and so on. As the number of nodes in a network increases, the number of routing nodes (e.g., Diameter routing nodes) usually increases proportionally. Large telecommunications networks that use the Diameter protocol may have multiple Diameter signaling routing nodes and correlation databases. To date, there is not a simple and/or efficient method or system for distributing data (e.g., state information) among multiple nodes that is both responsive and scalable.
FIG. 1 is block diagram illustrating a conventional telecommunications network, generally designated 100. Network includes multiple Diameter routing agents (DRAs) 102, each of which are configured to route Diameter messages within network 100 (e.g., intra-network). Other nodes (e.g., edge nodes) are configured to route Diameter messages between network 100 and other networks (e.g., inter-network). For example, a Diameter edge agent (DEA) 104 may route messages between multiple networks.
As illustrated in FIG. 1, DRAs 102 are configured to route Diameter messages between intra-network nodes within network 100 including, for example, between PCRF nodes 106, PCEF nodes (e.g., application servers AS 108), gateways GW 110, call/session control function CSCF 112 nodes, as well as to and from home subscriber server (HSS)/subscriber profile registry (SPR) nodes 114. DEA 104 routes messages between network 100 and nodes within other networks, such as for example, PCRF 106′ in another network.
In order for the group of DRAs 102 to collectively and/or functionally operate as a single DRA, it becomes necessary to maintain state information (i.e., information that associates a subscriber or session with a particular server) for Diameter sessions within network 100. Thus, each DRA 102 includes at least one database 116 for maintaining associations between a subscriber and a session within network 100. Subscribers may be identified by some form of identifier, such as for example only, an international mobile subscriber identity (IMSI), an internet protocol (IP) address, a unique subscriber ID, etc.
When a mobile subscriber 118 first joins network 100, a PCEF, such as CSCF 112, may send a request using a Gx interface (herein referred to as “a Gx request”) to one DRA 102 (e.g., DRA-1). Later, an application server, such as AS 108, may send a request using an Rx interface (herein referred to as “an Rx request”) to another DRA 102 (e.g., DRA-2). Because each DRA 102 (e.g., DRA-2) needs to know about the existence of the Diameter session set up by each other DRA 102 (e.g., DRA-1), the databases 116 (e.g., DB2) maintained and accessed at each DRA 102 (e.g., DRA-2) must contain the same information as each other database 116 maintained and accessed by each other DRA 102. Databases 116 containing the same information are herein referred to as being “coherent” databases.
Currently, there are two approaches to maintaining database coherency. A first method is replication, by which any change to one database triggers sending an update to each of the other databases. As networks grow in size (e.g., scale up), however, and more routing nodes are used and brought online, the number of databases for which coherence must be maintained also increases. As the number of databases increases, the amount of replication traffic increases non-linearly until a functional limit is reached. In other words, replication alone does not scale well.
A second method of maintaining database coherency is message-based, by which, if one database does not have the needed information, the node hosting the deficient database must query another node hosting another database to determine if the other database contains the needed information. If not, then a third node hosting a third database is queried, and so on, until either the information is found or it is determined that none of the queried databases contains the needed information. The message-based method may or may not generate less traffic than the replication method, depending upon the specific situation, however, this method tends to suffer high latency delays because of the time that it takes to query multiple nodes, one by one, to find information. In the conventional network 100 illustrated in FIG. 1, traffic relating to maintaining database coherency is depicted in dashed lines, and all other traffic is depicted in solid lines.
Network operators often select a single equipment vendor as the vendor of choice for certain functions. For example, a network operator may purchase all DRAs 102 from a same vendor, to ensure that all DRAs 102 are compatible and operate together correctly and/or seamlessly. In this scenario, DRAs 102 may use a vendor-specific or vendor-proprietary method to maintain database coherency.
Other network operators, however, may decide to purchase equipment that performs the same function from multiple vendors, to provide an additional form of redundancy. Should all of the equipment from one particular vendor fail because of a same software bug or become susceptible to a particular flaw or exploit, then there will be at least another set of equipment that is (hopefully) not likely to be similarly affected. This, however, creates a new set of problems. For example, networks having DRAs from different vendors cannot use a particular vendor's proprietary method to maintain database coherency. This forces the network to use a lowest-common-denominator approach such as the previously discussed replication or message-based methods.
Accordingly, in light of these disadvantages associated with the conventional approaches described above, there exists a need for methods, systems, and computer readable media for performing stateful Diameter routing with DRAs that use different mechanisms to achieve stateful routing.